GIT development branches for packagers?

[Andrew Lutomirski]

I have some trivial cleanups I want to make to a package a maintain.
These cleanups are trivial enough that I don't think they're worth a
new build.  Should I commit them to the master branch?  If so, I can
imagine a couple of issues:

 - A provenpackager could kick off a rebuild for whatever reason (e.g.
dependency soname bump).  That will (I think) inadvertently include my
changes.
 - I need to think about whether to add a changelog entry or not.  If
not, those changes might be included silently.  If yes, then I need to
think about what to do about the revision number.

The normal GIT approach would be to develop on another branch and to
merge when I want to build a new revision (the Fedora equivalent of
tagging a new release).  Should Fedora provide branches like
master-devel, f20-devel, etc that store pending changes?

Am I missing something really obvious here?

--Andy

[Jamie Nguyen]

On 14/01/14 20:41, Andrew Lutomirski wrote:
>  I have some trivial cleanups I want to make to a package a maintain.
>  These cleanups are trivial enough that I don't think they're worth a
>  new build.  Should I commit them to the master branch?  If so, I can
>  imagine a couple of issues:
>  
>   - A provenpackager could kick off a rebuild for whatever reason (e.g.
>  dependency soname bump).  That will (I think) inadvertently include my
>  changes.
>   - I need to think about whether to add a changelog entry or not.  If
>  not, those changes might be included silently.  If yes, then I need to
>  think about what to do about the revision number.
>  
>  The normal GIT approach would be to develop on another branch and to
>  merge when I want to build a new revision (the Fedora equivalent of
>  tagging a new release).  Should Fedora provide branches like
>  master-devel, f20-devel, etc that store pending changes? 
Committing spec changes without a subsequent build is a perfectly
reasonable thing to do. When doing spec clean-up, I would normally bump
the Release tag and add a changelog entry. This is essentially what
happens when packages are being reviewed for inclusion in Fedora.


-- 
Jamie Nguyen

[Kevin Fenzi]

On Tue, 14 Jan 2014 12:41:42 -0800
Andrew Lutomirski <luto(a)mit.edu&gt; wrote:

>  I have some trivial cleanups I want to make to a package a maintain.
>  These cleanups are trivial enough that I don't think they're worth a
>  new build.  Should I commit them to the master branch?  If so, I can
>  imagine a couple of issues: 
Sure. Note that you are welcome to build a new rawhide build at any
time, so even if it's not that big a change, it's not a problem to do a
build to just make sure everything is well, etc.

>   - A provenpackager could kick off a rebuild for whatever reason
> (e.g.
>  dependency soname bump).  That will (I think) inadvertently include my
>  changes. 
Yep. They would. But is that a problem? 

>   - I need to think about whether to add a changelog entry or not. 
> If
>  not, those changes might be included silently.  If yes, then I need to
>  think about what to do about the revision number. 
I would add a changelog entry and bump the release. 

There's happily no danger of running out of integers. 
 
>  The normal GIT approach would be to develop on another branch and to
>  merge when I want to build a new revision (the Fedora equivalent of
>  tagging a new release).  Should Fedora provide branches like
>  master-devel, f20-devel, etc that store pending changes? 
No. You could work in some local branch and merge back to Fedora, but
in practice if you are the maintainer there shouldn't be much need... 

>  Am I missing something really obvious here? 
Not sure. ;) 

kevin

[Kevin Kofler]

Kevin Fenzi wrote:
>  There's happily no danger of running out of integers. 
Well, isn't there some technical limit? Does rpmvercmp work on arbitrarily 
long integers or is it limited to something like 4294967295? And is there 
some character limit on the Release tag? :-)

(Now, to be fair, I don't think any of that would ever be an issue in 
practice.)

        Kevin Kofler

[Adam Williamson]

On Tue, 2014-01-14 at 12:41 -0800, Andrew Lutomirski wrote:
>  I have some trivial cleanups I want to make to a package a maintain.
>  These cleanups are trivial enough that I don't think they're worth a
>  new build.  Should I commit them to the master branch?  If so, I can
>  imagine a couple of issues:
>  
>   - A provenpackager could kick off a rebuild for whatever reason (e.g.
>  dependency soname bump).  That will (I think) inadvertently include my
>  changes. 
Yes, this will happen. Why do you think it's a problem, though? If your
changes are correct but you just don't think it's worth doing a new
build simply for them, why is it a problem if they get pulled in when
someone does another build for some *other* (presumably appropriate)
reason? It would seem like that's just what you'd want to happen.

>   - I need to think about whether to add a changelog entry or not. 
> If
>  not, those changes might be included silently.  If yes, then I need to
>  think about what to do about the revision number. 
One thing I've seen done is to add the line that actually describes the
change, above the last date/builder/NEVR line, *without* adding a new
line identifying the new build, date and builder. That way when someone
comes along and does a new build, they ought to see what should happen -
they should roll your partial entry into the entry they add for the
build.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Andrew Lutomirski]

On Tue, Jan 14, 2014 at 12:59 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Tue, 2014-01-14 at 12:41 -0800, Andrew Lutomirski wrote:
> > I have some trivial cleanups I want to make to a package a maintain.
> > These cleanups are trivial enough that I don't think they're worth a
> > new build.  Should I commit them to the master branch?  If so, I can
> > imagine a couple of issues:
> >
> >  - A provenpackager could kick off a rebuild for whatever reason (e.g.
> > dependency soname bump).  That will (I think) inadvertently include my
> > changes.
>
>  Yes, this will happen. Why do you think it's a problem, though? If your
>  changes are correct but you just don't think it's worth doing a new
>  build simply for them, why is it a problem if they get pulled in when
>  someone does another build for some *other* (presumably appropriate)
>  reason? It would seem like that's just what you'd want to happen. 
Depends how well I've tested.  I'd like to imagine that I never commit
anything broken anywhere, but this is empirically incorrect -- I break
development branches on a semi-regular basis.  I guess I'll just have
to be more cautious w/ Fedora :)

> >  - I need to think about whether to add a changelog entry or not.  If
> > not, those changes might be included silently.  If yes, then I need to
> > think about what to do about the revision number.
>
>  One thing I've seen done is to add the line that actually describes the
>  change, above the last date/builder/NEVR line, *without* adding a new
>  line identifying the new build, date and builder. That way when someone
>  comes along and does a new build, they ought to see what should happen -
>  they should roll your partial entry into the entry they add for the
>  build. 
That would work.

--Andy

[Tomas Mraz]

On Út, 2014-01-14 at 13:13 -0800, Andrew Lutomirski wrote:
>  On Tue, Jan 14, 2014 at 12:59 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > On Tue, 2014-01-14 at 12:41 -0800, Andrew Lutomirski wrote:
>  >> I have some trivial cleanups I want to make to a package a maintain.
>  >> These cleanups are trivial enough that I don't think they're worth a
>  >> new build.  Should I commit them to the master branch?  If so, I can
>  >> imagine a couple of issues:
>  >>
>  >>  - A provenpackager could kick off a rebuild for whatever reason (e.g.
>  >> dependency soname bump).  That will (I think) inadvertently include my
>  >> changes.
>  >
>  > Yes, this will happen. Why do you think it's a problem, though? If your
>  > changes are correct but you just don't think it's worth doing a new
>  > build simply for them, why is it a problem if they get pulled in when
>  > someone does another build for some *other* (presumably appropriate)
>  > reason? It would seem like that's just what you'd want to happen.
>  
>  Depends how well I've tested.  I'd like to imagine that I never commit
>  anything broken anywhere, but this is empirically incorrect -- I break
>  development branches on a semi-regular basis.  I guess I'll just have
>  to be more cautious w/ Fedora :)
>  
>  >
>  >>  - I need to think about whether to add a changelog entry or not.  If
>  >> not, those changes might be included silently.  If yes, then I need to
>  >> think about what to do about the revision number.
>  >
>  > One thing I've seen done is to add the line that actually describes the
>  > change, above the last date/builder/NEVR line, *without* adding a new
>  > line identifying the new build, date and builder. That way when someone
>  > comes along and does a new build, they ought to see what should happen -
>  > they should roll your partial entry into the entry they add for the
>  > build.
>  
>  That would work. 
I'd recommend rather the approach suggested by Kevin. Bump the release
and include a regular changelog entry. Just do not build. There is no
rule that all changeloged entries must be really built.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)

[Adam Williamson]

On Wed, 2014-01-15 at 11:29 +0100, Tomas Mraz wrote:
>  On Út, 2014-01-14 at 13:13 -0800, Andrew Lutomirski wrote:
>  > On Tue, Jan 14, 2014 at 12:59 PM, Adam Williamson <awilliam(a)redhat.com&gt;
> wrote:
>  > > On Tue, 2014-01-14 at 12:41 -0800, Andrew Lutomirski wrote:
>  > >> I have some trivial cleanups I want to make to a package a maintain.
>  > >> These cleanups are trivial enough that I don't think they're worth
> a
>  > >> new build.  Should I commit them to the master branch?  If so, I can
>  > >> imagine a couple of issues:
>  > >>
>  > >>  - A provenpackager could kick off a rebuild for whatever reason (e.g.
>  > >> dependency soname bump).  That will (I think) inadvertently include my
>  > >> changes.
>  > >
>  > > Yes, this will happen. Why do you think it's a problem, though? If your
>  > > changes are correct but you just don't think it's worth doing a new
>  > > build simply for them, why is it a problem if they get pulled in when
>  > > someone does another build for some *other* (presumably appropriate)
>  > > reason? It would seem like that's just what you'd want to happen.
>  > 
>  > Depends how well I've tested.  I'd like to imagine that I never commit
>  > anything broken anywhere, but this is empirically incorrect -- I break
>  > development branches on a semi-regular basis.  I guess I'll just have
>  > to be more cautious w/ Fedora :)
>  > 
>  > >
>  > >>  - I need to think about whether to add a changelog entry or not.  If
>  > >> not, those changes might be included silently.  If yes, then I need to
>  > >> think about what to do about the revision number.
>  > >
>  > > One thing I've seen done is to add the line that actually describes the
>  > > change, above the last date/builder/NEVR line, *without* adding a new
>  > > line identifying the new build, date and builder. That way when someone
>  > > comes along and does a new build, they ought to see what should happen -
>  > > they should roll your partial entry into the entry they add for the
>  > > build.
>  > 
>  > That would work.
>  
>  I'd recommend rather the approach suggested by Kevin. Bump the release
>  and include a regular changelog entry. Just do not build. There is no
>  rule that all changeloged entries must be really built. 
I have found this kind of phantom release a bit annoying in some really
esoteric situations - when the changelog indicates that there was, say,
a 1.2-6 build, but there never was, only 1.2-5 and 1.2-7 - but most of
the time it's not going to be a problem, yeah.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Andrew Lutomirski]

On Thu, Jan 16, 2014 at 10:15 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Wed, 2014-01-15 at 11:29 +0100, Tomas Mraz wrote:
> > On Út, 2014-01-14 at 13:13 -0800, Andrew Lutomirski wrote:
> > > On Tue, Jan 14, 2014 at 12:59 PM, Adam Williamson <awilliam(a)redhat.com&gt;
> wrote:
> > > > On Tue, 2014-01-14 at 12:41 -0800, Andrew Lutomirski wrote:
> > > >> I have some trivial cleanups I want to make to a package a maintain.
> > > >> These cleanups are trivial enough that I don't think they're
> worth a
> > > >> new build.  Should I commit them to the master branch?  If so, I can
> > > >> imagine a couple of issues:
> > > >>
> > > >>  - A provenpackager could kick off a rebuild for whatever reason (e.g.
> > > >> dependency soname bump).  That will (I think) inadvertently include my
> > > >> changes.
> > > >
> > > > Yes, this will happen. Why do you think it's a problem, though? If
> your
> > > > changes are correct but you just don't think it's worth doing a
> new
> > > > build simply for them, why is it a problem if they get pulled in when
> > > > someone does another build for some *other* (presumably appropriate)
> > > > reason? It would seem like that's just what you'd want to happen.
> > >
> > > Depends how well I've tested.  I'd like to imagine that I never commit
> > > anything broken anywhere, but this is empirically incorrect -- I break
> > > development branches on a semi-regular basis.  I guess I'll just have
> > > to be more cautious w/ Fedora :)
> > >
> > > >
> > > >>  - I need to think about whether to add a changelog entry or not.  If
> > > >> not, those changes might be included silently.  If yes, then I need to
> > > >> think about what to do about the revision number.
> > > >
> > > > One thing I've seen done is to add the line that actually describes
> the
> > > > change, above the last date/builder/NEVR line, *without* adding a new
> > > > line identifying the new build, date and builder. That way when someone
> > > > comes along and does a new build, they ought to see what should happen -
> > > > they should roll your partial entry into the entry they add for the
> > > > build.
> > >
> > > That would work.
> >
> > I'd recommend rather the approach suggested by Kevin. Bump the release
> > and include a regular changelog entry. Just do not build. There is no
> > rule that all changeloged entries must be really built.
>
>  I have found this kind of phantom release a bit annoying in some really
>  esoteric situations - when the changelog indicates that there was, say,
>  a 1.2-6 build, but there never was, only 1.2-5 and 1.2-7 - but most of
>  the time it's not going to be a problem, yeah. 
I can imagine this annoying anyone who does a mass rebuilt or a
similar set of rebuilds that aren't intended (by the one doing the
rebuilds) to change anything other than dependencies and, say, the
compiler version.  Sure, this *shouldn't* cause a problem if everyone
is appropriately careful, but I'm hesitant to trust things that
transparently deploy code when no has has explicitly asked for a
change to be deployed.

--Andy

[Toshio Kuratomi]

On Jan 16, 2014 10:19 AM, "Andrew Lutomirski" <luto(a)mit.edu&gt; wrote:
>  On Thu, Jan 16, 2014 at 10:15 AM, Adam Williamson <awilliam(a)redhat.com&gt;
wrote:
>  > On Wed, 2014-01-15 at 11:29 +0100, Tomas Mraz wrote:
>  >> On Út, 2014-01-14 at 13:13 -0800, Andrew Lutomirski wrote:
>  >> > On Tue, Jan 14, 2014 at 12:59 PM, Adam Williamson <
awilliam(a)redhat.com&gt; wrote:
>  >> > > On Tue, 2014-01-14 at 12:41 -0800, Andrew
> Lutomirski wrote:
>  >> > >> I have some trivial cleanups I want to make to a package a
maintain.
>  >> > >> These cleanups are trivial enough that I
> don't think they're 
worth a
>  >> > >> new build.  Should I commit them to the master
> branch?  If so, I 
can
>  >> > >> imagine a couple of issues:
>  >> > >>
>  >> > >>  - A provenpackager could kick off a rebuild for whatever reason
(e.g.
>  >> > >> dependency soname bump).  That will (I think)
> inadvertently 
include my
>  >> > >> changes.
>  >> > >
>  >> > > Yes, this will happen. Why do you think it's a problem, though? If
your
>  >> > > changes are correct but you just don't think
> it's worth doing a new
>  >> > > build simply for them, why is it a problem if they get pulled in
when
>  >> > > someone does another build for some *other*
> (presumably 
appropriate)
>  >> > > reason? It would seem like that's just what
> you'd want to happen.
>  >> >
>  >> > Depends how well I've tested.  I'd like to imagine that I never
commit
>  >> > anything broken anywhere, but this is empirically
> incorrect -- I 
break
>  >> > development branches on a semi-regular basis.  I guess
> I'll just have
>  >> > to be more cautious w/ Fedora :)
>  >> >
>  >> > >
>  >> > >>  - I need to think about whether to add a changelog entry or not.
 If
>  >> > >> not, those changes might be included silently.
>  If yes, then I 
need to
>  >> > >> think about what to do about the revision
> number.
>  >> > >
>  >> > > One thing I've seen done is to add the line that actually
describes the
>  >> > > change, above the last date/builder/NEVR line,
> *without* adding a 
new
>  >> > > line identifying the new build, date and builder.
> That way when 
someone
>  >> > > comes along and does a new build, they ought to
> see what should 
happen -
>  >> > > they should roll your partial entry into the entry
> they add for the
>  >> > > build.
>  >> >
>  >> > That would work.
>  >>
>  >> I'd recommend rather the approach suggested by Kevin. Bump the release
>  >> and include a regular changelog entry. Just do not build. There is no
>  >> rule that all changeloged entries must be really built.
>  >
>  > I have found this kind of phantom release a bit annoying in some really
>  > esoteric situations - when the changelog indicates that there was, say,
>  > a 1.2-6 build, but there never was, only 1.2-5 and 1.2-7 - but most of
>  > the time it's not going to be a problem, yeah.
>
>  I can imagine this annoying anyone who does a mass rebuilt or a
>  similar set of rebuilds that aren't intended (by the one doing the
>  rebuilds) to change anything other than dependencies and, say, the
>  compiler version.  Sure, this *shouldn't* cause a problem if everyone
>  is appropriately careful, but I'm hesitant to trust things that
>  transparently deploy code when no has has explicitly asked for a
>  change to be deployed.
>  
Yeah, I wouldn't trust my un built changes either :-).  But I think I'd go
with another of Kevin's options - go ahead and build in rawhide.  There's
really no downside to getting your this type of change out there sooner
rather than later.

-Toshio

[David Tardon]

Hi,

On Tue, Jan 14, 2014 at 12:41:42PM -0800, Andrew Lutomirski wrote:
>  I have some trivial cleanups I want to make to a package a maintain.
>  These cleanups are trivial enough that I don't think they're worth a
>  new build.  Should I commit them to the master branch?
>  
>  The normal GIT approach would be to develop on another branch and to
>  merge when I want to build a new revision (the Fedora equivalent of
>  tagging a new release).  Should Fedora provide branches like
>  master-devel, f20-devel, etc that store pending changes? 
You already have that "branch": it is your local repo :-) Nobody forces
you to push your changes before you are ready to do a build. And you can
use remote branches as well; you just need to pass --dist XY to fedpkg
for all operations, as it will not be able to recognize the release from
your branch name. E.g.:

git checkout -b f20-devel
git push origin f20-devel:f20-devel
# ... changes ...
fedpkg --dist f20 local
# ... check it builds ...
git commit -am '...'
git push

D.

[Vít Ondruch]

Dne 14.1.2014 21:41, Andrew Lutomirski napsal(a):
>  I have some trivial cleanups I want to make to a package a maintain.
>  These cleanups are trivial enough that I don't think they're worth a
>  new build.  Should I commit them to the master branch?  If so, I can
>  imagine a couple of issues:
>
>   - A provenpackager could kick off a rebuild for whatever reason (e.g.
>  dependency soname bump).  That will (I think) inadvertently include my
>  changes.
>   - I need to think about whether to add a changelog entry or not.  If
>  not, those changes might be included silently.  If yes, then I need to
>  think about what to do about the revision number.
>
>  The normal GIT approach would be to develop on another branch and to
>  merge when I want to build a new revision (the Fedora equivalent of
>  tagging a new release).  Should Fedora provide branches like
>  master-devel, f20-devel, etc that store pending changes?
>
>  Am I missing something really obvious here?
>
>  --Andy 
Actually I'd really love to see some possibility for private branches.
Now, it is possible to push whatever branch (take it literally) you have
in your local git repo into dist-git, but there is no way how to delete
it by myself.

For example, I am using branches to keep my .spec file aligned with
upstream development and I'd like to share it with other maintainers.
But this .spec file should never build in Rawhide unless it is approved
by FESCo.

Could you please add support for private branches? I.e. the branch which
starts by private- prefix could be pushed and deleted as well, non ff
commit should be allowed. Actually, better would be if only master, fxx
and elx are protected and others are unrestricted, but I am probably
asking too much.


Vít

[Dridi Boukelmoune]

On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Dne 14.1.2014 21:41, Andrew Lutomirski napsal(a):
> > I have some trivial cleanups I want to make to a package a maintain.
> > These cleanups are trivial enough that I don't think they're worth a
> > new build.  Should I commit them to the master branch?  If so, I can
> > imagine a couple of issues:
> >
> >  - A provenpackager could kick off a rebuild for whatever reason (e.g.
> > dependency soname bump).  That will (I think) inadvertently include my
> > changes.
> >  - I need to think about whether to add a changelog entry or not.  If
> > not, those changes might be included silently.  If yes, then I need to
> > think about what to do about the revision number.
> >
> > The normal GIT approach would be to develop on another branch and to
> > merge when I want to build a new revision (the Fedora equivalent of
> > tagging a new release).  Should Fedora provide branches like
> > master-devel, f20-devel, etc that store pending changes?
> >
> > Am I missing something really obvious here?
> >
> > --Andy
>
>  Actually I'd really love to see some possibility for private branches.
>  Now, it is possible to push whatever branch (take it literally) you have
>  in your local git repo into dist-git, but there is no way how to delete
>  it by myself.
>
>  For example, I am using branches to keep my .spec file aligned with
>  upstream development and I'd like to share it with other maintainers.
>  But this .spec file should never build in Rawhide unless it is approved
>  by FESCo.
>
>  Could you please add support for private branches? I.e. the branch which
>  starts by private- prefix could be pushed and deleted as well, non ff
>  commit should be allowed. Actually, better would be if only master, fxx
>  and elx are protected and others are unrestricted, but I am probably
>  asking too much. 
For private branches I'd rather see something along fas/branch.

With the '/' separator you can glob refspecs, and using your fas as a
prefix could enable automatic acls with less pain on the
infrastructure side (eg. allow anyone to manage and own private
branches at will).

Dridi

>  Vít
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Haïkel]

/me wants the ability to push force on *private* branches


2014/1/15 Dridi Boukelmoune <dridi.boukelmoune(a)gmail.com&gt;

>  On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch
> <vondruch(a)redhat.com&gt; wrote:
>  > Dne 14.1.2014 21:41, Andrew Lutomirski napsal(a):
>  >> I have some trivial cleanups I want to make to a package a maintain.
>  >> These cleanups are trivial enough that I don't think they're worth a
>  >> new build.  Should I commit them to the master branch?  If so, I can
>  >> imagine a couple of issues:
>  >>
>  >>  - A provenpackager could kick off a rebuild for whatever reason (e.g.
>  >> dependency soname bump).  That will (I think) inadvertently include my
>  >> changes.
>  >>  - I need to think about whether to add a changelog entry or not.  If
>  >> not, those changes might be included silently.  If yes, then I need to
>  >> think about what to do about the revision number.
>  >>
>  >> The normal GIT approach would be to develop on another branch and to
>  >> merge when I want to build a new revision (the Fedora equivalent of
>  >> tagging a new release).  Should Fedora provide branches like
>  >> master-devel, f20-devel, etc that store pending changes?
>  >>
>  >> Am I missing something really obvious here?
>  >>
>  >> --Andy
>  >
>  > Actually I'd really love to see some possibility for private branches.
>  > Now, it is possible to push whatever branch (take it literally) you have
>  > in your local git repo into dist-git, but there is no way how to delete
>  > it by myself.
>  >
>  > For example, I am using branches to keep my .spec file aligned with
>  > upstream development and I'd like to share it with other maintainers.
>  > But this .spec file should never build in Rawhide unless it is approved
>  > by FESCo.
>  >
>  > Could you please add support for private branches? I.e. the branch which
>  > starts by private- prefix could be pushed and deleted as well, non ff
>  > commit should be allowed. Actually, better would be if only master, fxx
>  > and elx are protected and others are unrestricted, but I am probably
>  > asking too much.
>
>  For private branches I'd rather see something along fas/branch.
>
>  With the '/' separator you can glob refspecs, and using your fas as a
>  prefix could enable automatic acls with less pain on the
>  infrastructure side (eg. allow anyone to manage and own private
>  branches at will).
>
>  Dridi
>
>  > Vít
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

[Vít Ondruch]

Dne 15.1.2014 17:51, Dridi Boukelmoune napsal(a):
>  On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch
> <vondruch(a)redhat.com&gt; wrote:
> > Dne 14.1.2014 21:41, Andrew Lutomirski napsal(a):
> >> I have some trivial cleanups I want to make to a package a maintain.
> >> These cleanups are trivial enough that I don't think they're worth a
> >> new build.  Should I commit them to the master branch?  If so, I can
> >> imagine a couple of issues:
> >>
> >>  - A provenpackager could kick off a rebuild for whatever reason (e.g.
> >> dependency soname bump).  That will (I think) inadvertently include my
> >> changes.
> >>  - I need to think about whether to add a changelog entry or not.  If
> >> not, those changes might be included silently.  If yes, then I need to
> >> think about what to do about the revision number.
> >>
> >> The normal GIT approach would be to develop on another branch and to
> >> merge when I want to build a new revision (the Fedora equivalent of
> >> tagging a new release).  Should Fedora provide branches like
> >> master-devel, f20-devel, etc that store pending changes?
> >>
> >> Am I missing something really obvious here?
> >>
> >> --Andy
> > Actually I'd really love to see some possibility for private branches.
> > Now, it is possible to push whatever branch (take it literally) you have
> > in your local git repo into dist-git, but there is no way how to delete
> > it by myself.
> >
> > For example, I am using branches to keep my .spec file aligned with
> > upstream development and I'd like to share it with other maintainers.
> > But this .spec file should never build in Rawhide unless it is approved
> > by FESCo.
> >
> > Could you please add support for private branches? I.e. the branch which
> > starts by private- prefix could be pushed and deleted as well, non ff
> > commit should be allowed. Actually, better would be if only master, fxx
> > and elx are protected and others are unrestricted, but I am probably
> > asking too much.
>  For private branches I'd rather see something along fas/branch.
>
>  With the '/' separator you can glob refspecs, and using your fas as a
>  prefix could enable automatic acls with less pain on the
>  infrastructure side (eg. allow anyone to manage and own private
>  branches at will).
>
>  Dridi 
Yes, that is a good idea, why not? Anything would help :)


Vít

[Richard W.M. Jones]

On Wed, Jan 15, 2014 at 02:16:29PM +0100, Vít Ondruch wrote:
>  Actually I'd really love to see some possibility for private
> branches.
>  Now, it is possible to push whatever branch (take it literally) you have
>  in your local git repo into dist-git, but there is no way how to delete
>  it by myself. 
[...]

Isn't it already possible to add branches?  eg the kernel seems
to have a whole lot of private-looking branches:

http://pkgs.fedoraproject.org/cgit/kernel.git/refs/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Vít Ondruch]

Dne 15.1.2014 18:12, Richard W.M. Jones napsal(a):
>  On Wed, Jan 15, 2014 at 02:16:29PM +0100, Vít Ondruch wrote:
> > Actually I'd really love to see some possibility for private branches.
> > Now, it is possible to push whatever branch (take it literally) you have
> > in your local git repo into dist-git, but there is no way how to delete
> > it by myself.
>  [...]
>
>  Isn't it already possible to add branches?  eg the kernel seems
>  to have a whole lot of private-looking branches:
>
>  http://pkgs.fedoraproject.org/cgit/kernel.git/refs/
>
>  Rich.
>  
Yes, as I said in the quote, you can just *add* branches, you cannot
remove them, you cannot force them ...


Vít