On Tue, Jun 4, 2013 at 4:15 PM, Josh Elser <josh.el...@gmail.com> wrote: > On 6/4/13 2:34 PM, Christopher wrote: >> >> Personally, I'm fine with not having a super-long running release >> branch, but I like them for a few reasons: [snip] > I just want to keep make note that this will affect things much more than > previously in SVN as a merge is more than a guess at metadata. > > If you have long-lived branches, this necessitates that there are very many > viable options in which a bug-fix can be applied (any branch at all). Not > keeping these around will force the developer to think about where their fix > is supposed to go (earliest, non-EOL'ed version). [snip]
Good point. > >> I think branches should be hierarchical for subprojects and contribs, >> as in: contrib/InstamoOrWhatever (unless there's a better way to >> handle contribs...?) > > > I believe we'll need to make separate repos for subprojects and contribs. > This is one of the things I need to investigate how it's currently handled. > New repos are certainly the easiest to manage. I agree, of course, and that's the preferred option if INFRA permits this. But this is a workable alternative if they don't. [snip] > Point being, I do not want to preclude developers from making tags unless > it's an ASF release as I believe this gimps Git quite a bit. IMO, for tags, > the line should be drawn between "internal" and "external". Tags advertised > or intended for public use should (probably) be voted on, while > internal-only intended (doesn't preclude someone from finding and > downloading themselves) are encouraged. > Understandable, as long as the line is drawn. -- Christopher L Tubbs II http://gravatar.com/ctubbsii
